@viniarck I'll provide the migration script, but anyway I don't think this PR should ship with 2022.3.x, it is a change for 2023.1. What do you think about creating a branch for the changes expected to ship with 2023.1?

@viniarck I'll provide the migration script, but anyway I don't think this PR should ship with 2022.3.x, it is a change for 2023.1. What do you think about creating a branch for the changes expected to ship with 2023.1?

@ajoaoff, yes, we won't ship to 2022.3.X, when I read my comment again, I summarized it too much, what I meant to write was, since AmLight will deploy 2022.3, and this will be shipped to master and eventually 2023.1, then ideally they can use this script before using/deploying 2023.1 to keep the collection with dl_vlan type the same.

Antonio, if you could also update the openapi.yml spec as well, that'd be great, we'll start reusing the openapi-core validate decorator that you've implemented to also validate some endpoints on flow_manager.

Regarding a new branch for 2023.1 although it's a great idea, at this time, I'd rather maintain master and then on upstream only keep tag and start creating old branches for patched versions since the tag by itself wouldn't suffice, sometimes we don't have a new version scope defined yet, and then contributions might also land on master. We can keep evolving this discussion if we can benefit from a simpler workflow.

This PR also handles any and untagged cases I am working on. mef_eline issue #219

@viniarck and @ajoaoff, since this is a major change that will impact other Napps, IMO we have to increase the API version and keep the old one compatible with the previous format—maybe providing an abstraction between the two versions (which will convert int to string).

Another strategy would be supporting both int and string.

WDYT?

Good point. If we decide to unify the string format for dl_vlan, of_core will be affected since the vlan_id is returned as int (here). Combination of int and string is already supported, here vlan with mask it is returned as string.
Minor detail, it is easier/faster to differentiate strings from integers while writing code since they represent special cases.

Agreed @italovalcy @Alopalao, I tend to avoid mixing different type for the same field dl_vlan, but it's becoming evident that dl_vlan being Optional[Union[str, int]] would make things way simpler, and only use a str when setting a mask as of_core has been designed, not completely breaking compatibility with the API as well while extending it to support the mask. @ajoaoff could you adapt this part? That way we also wouldn't need the script as well. Thanks

Regarding bumping v3 though, let's leave it to when we address the other validations in general on issue #43 that we have on our radar (cookie_mask mandatory for deletions an so on).